上一篇文章说了 x402 的设计动机：让 AI Agent 在取数据的同一瞬间付钱。这篇把技术链路拆开——从客户端敲下请求到钱包里的 USDC 划走，中间发生了什么，每个环节由谁负责。

整个支付动作被压缩在一次请求-质询-重试的 HTTP 交互里：首次请求拿到 402 质询，客户端签名后重试，服务器验证并结算。没有独立的支付流程，没有跳转页面，没有二次确认。客户端、服务器、Facilitator、区块链四方配合，把“付款”从十几步的人类操作压缩成毫秒到秒级的机器握手。

一次支付的十步链路

整体时序如下（四方参与：客户端、资源服务器、Facilitator、区块链）：

客户端                   资源服务器              Facilitator              区块链
  │── 1. GET /数据 ──────>│                        │                       │
  │<─ 2. 402 + 质询 ─────│                        │                       │
  │  （钱包离线签名）      │                        │                       │
  │── 3. 带签名重试 ─────>│                        │                       │
  │                       │── 4. POST /verify ───>│                       │
  │                       │<─ 5. 验证通过 ────────│                       │
  │                       │── 6. POST /settle ───>│── 7. 赞助 Gas 广播 ──>│
  │                       │<─ 9. 结算回执 ────────│<─ 8. 链上确认 ────────│
  │<─ 10. 200 + 数据 ─────│                        │                       │

官方流程里，服务器在验证通过后会先执行请求，再通过 Facilitator 结算；下面按“质询 → 签名 → 验证与结算”三组动作展开。

第一组：质询（步骤 1–2）——服务器说“请付钱”

第一步没有任何特殊之处。客户端（AI Agent、脚本、甚至浏览器）向受保护的 API 端点发起普通 GET 请求，不带任何密钥。对服务器来说这就是一次未认证请求。

第二步是 x402 的核心动作。服务器上的 x402 中间件拦截请求，发现路由需要付费且请求没带支付凭证，返回 HTTP 402 Payment Required，并在响应头里附上付款条件。

x402 没有用 HTTP 标准里现成的 WWW-Authenticate 头：那个头是给 401 认证挑战用的（Basic、Digest、Bearer）。x402 V2 规范 定义了专用的 PAYMENT-REQUIRED 响应头，值是 Base64 编码的 JSON，同时响应体里也会带一份明文 JSON，照顾不支持解析头的旧客户端。

解码后的质询长这样：

{
  "x402Version": 2,
  "resource": {
    "url": "https://api.example.com/premium-data",
    "description": "访问付费数据",
    "mimeType": "application/json"
  },
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:8453",
      "amount": "10000",
      "asset": "0x833589fCD6eDb6E08f4c7c32d4f71b54bdA02913",
      "payTo": "0xMerchantRecipientAddress",
      "maxTimeoutSeconds": 60,
      "extra": {
        "name": "USDC",
        "version": "2"
      }
    }
  ]
}

字段含义：

accepts 是数组：一个接口可以同时接受 Base 上的 USDC、Solana 上的 USDC、Stellar 上的 EURC……客户端按自己的钱包情况选一个。这是 x402 多链设计的起点。

第二组：签名（步骤 3）——钱包离线签字，零 Gas 成本

客户端 SDK 截获 402 响应，解码质询，先核对价格是否在本地预设的预算上限内（这是 Agent 的安全阀），然后调用钱包私钥做离线签名。

这一步不向区块链广播任何交易，不消耗任何 Gas。客户端只是用私钥对支付参数做了一次密码学签名，表达“我愿意为这笔钱授权”。签名结果放进 PAYMENT-SIGNATURE 请求头（Base64 JSON），重新发起请求。

不同链的签名方式不一样：

EIP-3009 有一个对 AI 场景很关键的设计：它的 nonce 是随机数，不是传统 EOA 的顺序计数器。这意味着 Agent 可以高并发发起多笔支付，交易之间不会互相碰撞阻塞——顺序 nonce 的账户做不到这一点。

第三组：验证与结算（步骤 4–9）——Facilitator 承担验证与结算

服务器收到带签名的重试请求后，并不会自己去验证签名、查余额、广播交易：那样服务器就得持有私钥、跑区块链节点，重量级且不安全。x402 把验证和结算外包给链下中立协作者（Facilitator）。

Facilitator 干三件事：

1. 验证（POST /verify）：解析 PAYMENT-SIGNATURE，按方案做核验：签名是否真实（确认是买家私钥签署且参数未被篡改）、钱包余额是否足够、授权参数（金额、有效期）是否满足质询要求，必要时模拟执行转账。
2. 合规过滤：广播前执行 KYT/OFAC 类合规扫描（部分托管 Facilitator 的默认行为，如 Coinbase CDP）。
3. 结算（POST /settle）：把包含客户端签名的交易打包广播上链。Facilitator 自己当 Gas 赞助方，代付链上 Gas 费（在 Facilitator 提供赞助的前提下，买家不需要持有任何 ETH/SOL 来付 Gas）。

最后一步，链上确认完成，Facilitator 把结算回执返回服务器，服务器返回 200 OK + 数据，响应头里带 PAYMENT-RESPONSE 供客户端留存凭证，一次支付到此结束。

几个设计细节

买家不需要 Gas，因为买家的签名是“授权”，不是“交易”。真正把授权变成链上交易的是 Facilitator，它作为元交易发起者垫付 Gas。对于智能钱包（ERC-4337）场景，Facilitator 还可以对接 Paymaster 服务，由赞助方代付 Gas。Agent 的钱包里只需要有 USDC 本身。

Facilitator 不能多扣钱。 它是非托管的：手里只有买家签名的授权数据，授权额度精确到金额，且 to 地址、value 都被签名锁死。Facilitator 只能把交易广播上链，改不了任何参数——这是“推送式支付”和传统“拉取式支付”的本质区别。推送式支付减少的是过度授权风险，不消除合规审查：Facilitator 的 KYT/OFAC 扫描本身就是风控的一环，传统网关需要 KYC 是因为它能从你的账户划任意额度。

服务器把验证外包的原因：保持无状态、无密钥，只需要信任自己配置的 Facilitator。这也意味着服务器对 Facilitator 有依赖——选谁，谁就有能力（合法范围内）替它处理支付。

边界与代价

这套链路不是没有代价。三个现实问题：

1. Facilitator 是中心化信任点：验证和结算集中在一个第三方手里，服务器的可用性和结算时效取决于它。生态里已有多个 Facilitator 可选（Coinbase CDP、OpenZeppelin 等），但协议本身不强制去中心化。
2. 只解决了“付款”这一件事：发票、退款、纠纷仲裁都在协议之外（x402r 退款协议、PEAC 可验证收据是生态里的补充方案，后面文章展开）。
3. 链上最终性有延迟：虽然验证是毫秒级，但链上确认（尤其需要多确认的安全场景）仍需数秒。对“取一次数据付一次钱”的场景够用，对亚秒级实时场景需要评估。

小结